# 前言
上一章是 Docker 的一些基础用法, 并且我们已经通过 Docker 构建了一个专门用于打包的 Docker 镜像,那么本章,本将借助 Jenkins 的 pipeline 流水线,构建一套适配多端的 job。
# 技术方案设计
照例,在正式开发之前进行了一轮技术预研,先将预研的方案理一下
# 脚本全量流程 + when 条件
一个 pineline 流水线将所有的状态流程都是预设好的,例如全量的流程从 dev -> test -> deploy 这种,可以通过参数 + when 条件语句跳过指定流程
优势:
这个方案是最简单的,同时开发成本最低。
劣势:
虽然是简单的方案,但是脚本相对于固定,如果有全新的流程是需要重新开发新的 pipeline 流水线。
# pipeline scm
通过 pipeline scm 在拉取 git 项目的同时读取 git 项目中的配置文件(Jenkinsfile),进行项目构建。
优势:
相比第一种比较灵活,在项目构建之前通过 gitlab api 的方式去修改 Jenkinsfile,达到一个动态生成流水线的目的。
劣势:
需要通过 gitlab api 去修改 Jenkinsfile,容易引起冲突。
# 修改 Jenkinsfile
创建 10 个 job,关闭单 job 的并发功能,直接通过 Jenkins Api 修改对应的 Jenkinsfile,然后手动维护任务队列。
优势:
自定义化程度非常高,且与项目代码完全隔离,不需要修改项目中的配置文件。
劣势:
Jenkins 的 job 自带并发队列,手动维护队列增加开发成本。
# blue ocean
使用 blue ocean 关联源码仓库,修改 Jenkinsfile 再运行,这种方案与第二种虽然过程不同但结果基本类似,所以优缺点基本相通
# 最后方案
根据上述 4 个方案的优缺点,结合现有的人力可以针对性的选择,那么对我们来说,第一种方案的性价比是最高的。
# Jenkinsfile
选定方案之后,我们就需要开发对应的 pipeline 脚本了。
这里也不过多介绍语法的详细,想要了解更多的同学们可以点击 API 文档地址查看更多
# 创建 stage
首先创建全量 stage
pipeline {
agent any
stages {
stage('Pre Git') {
steps {
script {
echo "pre git"
}
}
}
stage('Pre Dependencies') {
steps {
script {
echo "check node_modules,${params.CACHE}"
}
}
}
stage('build') {
steps {
script {
echo "build project"
}
}
}
stage('test') {
steps {
script {
echo "test case"
}
}
}
stage('deploy') {
steps {
script {
echo "deploy project"
}
}
}
}
如上,我们创建了 5 个 stage:
- Pre Git:拉取项目
- Pre Dependencies:安装依赖
- build:构建
- test:测试
- deploy: 发布
# Pre Git 拉取项目
拉取项目分两种
- 项目未拉取,这种情况很简单,直接使用如下命令即可:
